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1.  Introduction 


Office  automation  can  be  defined  as  the  replacement  of  manual  office 
activities  by  identical  or  similar  activities  which  automate  means  of 
doing  office  work.  An  office  activity  refers  to  any  activity  in  an 
office,  such  as  filling  out  a  form,  sending  a  message,  entering  infor¬ 
mation  into  a  file,  making  a  decision  to  route  a  form,  etc.  An  office 
procedure  refers  to  a  structured  set  of  office  activities  for  the 
accomplishment  of  a  specific  office  task,  such  as  scheduling  a  meet¬ 
ing,  processing  a  mortgage  application  form,  reviewing  a  paper,  etc. 
An  office  usually  consists  of  a  number  of  work  sta  Lions  or  simply 
stations .  The  work  stations  are  interconnec ted  by  a  communication 
network  to  serve  as  a  message  exchange  system. 

The  first  step  in  office  automation  is  usually  the  partial  (or  total) 
replacement  (or  enhancement)  of  the  office  desks  by  terminals,  word- 
processors  or  small  computer  systems  which  are  interconnected  by  an 
electronic  message  exchange  system.  In  other  words,  initially  office 
automation  aims  at  the  automation  of  devices  and  improvement  of  the 
communication  network  (message  exchange  system). 

The  second  step  in  office  automation  is  to  take  advantage  of  the  elec¬ 
tronic  desks,  and  replace  some  manual  office  procedures  by  computer¬ 
ized  procedures.  At  some  work  stations,  manual  intervention  is  still 
necessary  for  data  entry  and  decision-making .  Some  work  stations  may 
be  partially  automated,  with  some  activities  managed  by  ttie  electronic 
desk.  Some  other  work  stations  may  be  entirely  automated  using  compu¬ 
terized  office  procedures. 


Since  the  first  and  ultimate  goal  of  office  automation  is  to  automate 


office  activities,  it  is  important  to  unde '-stand  the  problems  related 
to  office  activities  management.  In  this  paper,  we  will  approach  the 
problem  of  office  activities  management  from  the  database  viewpoint. 
Database  alerting  techniques  are  developed  to  serve  the  purpose  of 
office  activities  management.  A  conceptual  framework  for  office  in¬ 
formation  system  design  is  presented  in  Section  2.  Section  3 
discusses  simple  database  alerters  and  implementation  techniques. 
Existential  alerters  and  time  alerters  are  discussed  in  Section  4.  In 
Section  5,  an  example  of  journal  editing  is  described  in  detail  Lo 
clarify  concepts.  In  Section  6,'  alerter  system  stability  is  dis¬ 
cussed.  Some  concluding  remarks  are  given  in  Section  7. 


2.  A  Conceptual  Framework  for  Office  Information  System  Design 
2.1.  Event  Monitoring  Using  Database  Alerters 

One  of  the  major  problems  in  office  automation  is  the  coordination  and 
integration  among  various  tasks.  In  the  real  world,  actions  are  usu¬ 
ally  triggered  due  to  a  change  of  state  of  a  certain  event.  Some  of 
these  actions  are  time-related  routine  operations,  for  example,  rout¬ 
ing  a  meeting  notice  among  a  group  of  people.  Such  routine  operations 
are  often  periodically  scheduled.  Some  of  these  actions  are  predeter¬ 
mined,  for  example,  managing  an  editorial  office  which  requires  the 
coordination  of  a  number  of  predetermined  tasks.  Such  predetermined 
actions  are  usually  both  event-based  and  time-related.  When  we  con¬ 
sider  the  design  of  an  office  information  system,  the  monitoring  of 
events,  and  the  scheduling  of  predetermined  and  time-related  routine 
activities  arc  the  main  functions  that  an  office  information  system 
can  perform  and  thereby  improve  office  efficiency  and  increase 
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productivity . 


An  office  information  system  requires  the  support  of  a  database 
management  system  for  the  storage  and  manipulation  of  office  informa¬ 
tion.  Moreover,  the  database  management  system  should  also  he  capable 
of  responding  to  external  events.  Database  systems  are  usually  pas¬ 
sive,  in  the  sense  that  they  only  respond  to  externally  generated 
information  retrieval/manipulation  requests,  but  cannot  take  other 
actions  spontaneously.  The  recent  development  of  database  alerting 

techniques  have  changed  the  character  of  the  database  system  from  a 

/ 

passive  one  to  an  active  one.  Database  alerters  are  first  Introduced 
by  Buneman  [BUNEMAN77,  79].  To  clarify  the  concept,  consider  the  fol¬ 
lowing  examples: 

Example  1_:  "Report  the  name  and  temperature  of  any  station  at 
which  the  temperature  falls  below  ten  degrees  Centigrade." 

Example  2_ :  "Report  the  number  and  owner  of  any  account  from  which 
more  than  $500  is  drawn." 


In  each  of  the  above  example,  the  user  wishes  to  be  informed  when  cer¬ 
tain  exception  condition  occurs.  The  exception  condition  and  the 
prescribed  message  sending  action  form  a  <condition,  action>  pair. 
Such  rules  are  called  alerter  rules. 


Alerter  rules  can  be  used  to  monitor  state  transitions  in  a  database. 
The  current  contents  of  a  database  determine  its  "state".  If  we  ag¬ 
gregate  the  database  states  into  two  states,  called  the  IN  state  (when 
an  exception  condition  Is  met)  and  the  OUT  state  (when  an  exception 
condition  is  not  met),  then  an  alerter  is  triggered  and  an  alert 
message  is  generated  or  actions  are  invoked,  whenever  the  database 
transits  to  an  IN  state.  Such  state  changes  are  affected  only  by 
database  updates.  Therefore,  to  install  database  alerters,  we  need 
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only  monitor  database  updates.  The  alerting  subsystem  In  Figure  1 
illustrates  this  concept. 

Alerter  rules  therefore  can  be  used  to  monitor  database  updates  and 
trigger  actions  whenever  certain  conditions  regarding  database  updates 
are  satisfied.  With  alerter  rules,  database  updates  will  automatical¬ 
ly  cause  prespecified  actions  to  take  place.  Thus  the  database  system 
can  take  on  an  active  role  in  events  monitoring. 

It  should  be  noted  that  actions  triggered  by  an  alerter  are  viewed  as 
side-effects  of  database  updates.  The  failure  of  performing  these 
actions  does  not  necessarily  cause  the  database  updates  to  be  rolled 
back.  This  constitutes  the  basic  difference  between  alerters  in  an 
alerter  system  and  triggers  in  an  integrity  system,  such  as  the 
trigger  mechanism  proposed  for  system  R  [ESUAK76). 

2.2.  Activity  Management  in  Office  Information  Systems 

An  office  information  system  is  a  message-driven  system.  Work  sta¬ 
tions  exchange  messages,  which  cause  certain  office  activities  to  be 
performed.  In  Figure  l,  we  present  the  component  subsystems  of  an 
office  information  system. 

Figure  1  depicts  the  relationship  among  the  database  system  (DUMS), 
the  alerting  subsystem  (AS),  the  office  manager  (OM)  ,  the  activity 
agents  (AA),  and  the  intelligent  coupler  (IC).  The  user  agent  coimimn* 
icates  with  the  user  interface,  called  the  intelligent  coupler,  by 
messages  or  forms.  The  intelligent  coupler  performs  the  translation 
of  user  queries  [C!IANG78b,  79].  It  can  also  interact  with  the  user  to 
complete  an  intelligent  form  [ZISMAN77]  (or  interactive  letter 
[ ANDEK76  ]  )  . 
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The  intelligent  coupler  sends  user  dat^iba  ;e  retrieval  and  update  mes¬ 
sages  to  the  database  system.  The  database  consists  of  a  user  data¬ 
base  and  an  alerter  database,  both  managed  by  the  database  system. 
The  alerter  database  is  used  to  store  the  alerter  rules.  The  database 
system  sends  messages  to  the  averting  subsystem,  containing  descrip¬ 
tion  of  every  completed  update  or  failed  update. 

The  alerting  subsystem  screens  database  updates  to  detect  the  oc¬ 
currence  of  important  events.  Therefore,  the  alerting  subsystem  can 
be  generally  viewed  as  a  screening  program  or  a  f il ter  associated  with 
the  database  system.  When  an  event  occurs,  the  alerting  subsystem  can 
either  send  an  alert  message  to  the  intelligent  coupler  (which  in  turn 
informs  the  user  agent),  or  send  an  activity  request  to  the  office 

M 

manager  to  initiate  office  activities. 

The  office  manager  manages  office  activities.  It  receives  activity 
request  either  indirectly  from  the  alerting  subsystem,  or  directly 
from  the  intelligent  coupler.  The  office  manager  then  schedules  and 
performs  office  procedures  by  calling  upon  one  or  many  activity 
agents.  Therefore,  the  office  manager  is  functionally  analogous  to 
the  scheduler  in  an  operating  system. 

An  activity  agent  can  he  regarded  as  an  office  specialist,  capable  of 
performing  some  well-defined  office  activity  [ZISMAN77].  For  example, 
the  activity  agent  can  be  a  form  generation  program,  a  report  genera- 
tor,  an  editing  program,  etc.  When  an  activity  agent  completes  its 
task,  it  sends  an  activity  completion  message  to  the  office  manager, 
which  may  then  schedule  other  activities. 

The  activity  agent  can  send  messages  to  the  intelligent  coupler,  which 
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then  presents  the  information  to  the  user  agent.  The  activity  agent 
can  also  perform  database  retrieval/update  operations,  which  may  lead 
to  triggering  of  alerters  and  scheduling  of  additional  activities. 


The  alerting  subsystem,  t he  office  manager,  and  the  activity  agents, 
together  form  the  activity  management  system  (AMS),  which  monitors 
events  and  initiates,  schedules,  and  perforins  office  activities 
[CHANG80].  The  activity  management  system  is  therefore  the  most  im* 
portant  part  of  the  office  information  system. 

2.3.  Office  Procedure  Model 

To  describe  the  relationships  among  office  activities,  databases,  and 
alerters,  we  adopt  the  following  formalism:  a  rectangular  box  is  used 
to  denote  a  file  Ri,  a  diamond -shaped  box  an  alerter  rule  A j ,  and  a 
circle  any  activity  or  process  Pk.  If  an  activity  or  process  requires 
user  interaction,  it  is  denoted  by  a  double  circle.  A  triangle  is 
used  to  denote  a  message  ui  or  a  form  Fj.  An  arrow  leading  to  the 
base  of  a  triangle  indicates  message  reception,  and  an  arrow  emanating 
from  the  vertex  of  a  triangle  indicates  message  transmission.  The 
possible  relationships  are  summarized  as  follows: 

(1)  File  access:  1  Ki|  -*>>  (P^) 

Kile  Ri  is  accessed  by  process  Pk. 

(2)  File  update:  ^Pk)  --»  [  Ki  |  orl(/\J^>-->>|  Rl| 

File  Ri  is  updated  by  process  Pk  or  alerter  rule  Aj. 

We  say  that  Pk  or  Aj  affects  file  Ri. 

(3)  Alerter  triggering:  |1TT1  _ 

Update  of  file  Ri  may  trigger^ alerter  Aj.  The  alert  condition  can 
be  written  beneath  the  directed  arc.  We  say  that  Aj  monitors  file 
Ri  for  triggering. 

(4)  Activity  invocat.1on:<^ij^>.-->(p^ 

Alerter  Aj  invokes  process  PJTT 

(5)  Activity  precedence :  ^k) --> ^Pm) 

Process  Pk  precedes  (and  invokes)  process  Pk. 
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(6) 

(7) 


Alerter 

Alerter 

Alerter 

Alerter 


creation:  v\^<=s=>'^r^  or 
Aj  or  process  l’k  creates 

deletion:  or 

Aj  or  process  Pk  deletes 


(8)  Message  input:  j^>-  ->>  [MESSAGE 


Input  message  u  is  stored  in  a  message  file. 


(9) 


form  out[ 
Process  PI 


put:  ©--» 

Pi  generates  out pi 


tput  form  Fj. 


(10) 


Form  interaction  process: 


Process  Pi  sends  form  Fj  to  user  agent  to  obtain 
information.  When  form  Fj  is  completed  by  user, 
continues . 


additional 
process  Pi 


(11)  Alerter  ON:  111 j  1 - 

ON  ,  , 

Update  of  file  Ri  may  enable  alerter  Aj.  The  ON  condition 
can  be  written  beneath  the  directed  arc.  We  say  that  Aj 
monitors  file  Ri  for  ON  condition. 


(12) 


Alerter  OFF: 


Update  of  file  Ri  may  destroy  alerter  Aj. 
can  be  written  beneath  the  directed  arc. 
monitors  file  Ri  for  OFF  condition. 


The  0 F F  c  o  n  d i t i o  n 
We  say  t  ha  t  Aj 


(13)  Time  clock:  ~» |TIMK~ 

TIME  file  is  set  to  t.  Since  TIME  file  is  often  a  conceptual 
device  (see  Section  4),  the  update  of  TIME  file  can  be  omitted 
'in  an  0PM  specification. 


With  these  formal  notations,  we  can  graphically,  depict  office  pro¬ 
cedures  and  analyze  how  they  can  be  executed  by  an  office  information 
system.  Such  a  formal  model  is  called  the  office  procedure  model 
(PPM) .  This  knowledge  model  can  also  be  stored  in  the  database.  It 
is  accessed  by  the  alerting  subsystem  to  c?heck  for  alerter  database 
consistency.  It  is  also  accessed  by  the  office  manager  to  schedule 
and  control  concurrent  activities  invoked  by  the  office  manager,  and 
to  check  for  alerter  system  stability  (see  Section  6). 
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3.  Simple  Alerters  and  Implementation  Issues 

Simple  alerters  monitor  database  updates  of  simple  database  objects, 
usually  records  in  a  file  (or  tuples  in  a  relational  file,  if  we  use 
the  relational  database  terminology).  To  specify  a  simple  alerter,  we 
need  to  specify  the  following: 

(1)  Name  of  alerter:  This  is  a  unique  symbolic  name  to  identify  an 

alerter. 

(2)  Type  of  update  operation  to  be  monitored:  Tor  updates  of  records 
in  a  file,  there  are  three  types  of  updates:  insertion  of  a  new 
record,  deletion  of  an  old  record,  and  modification  of  an  old  record. 
The  three  update  types  are  denoted  by  "i",  "d”,  and  "m",  respectively. 

(3)  Name  of  database  object  to  be  monitored:  Tor  monitoring  of  record 
updates  in  a  file,  this  will  consist  of  two  parts: 

(3.1)  file  name  (or  relation  name),  and 

(3.2)  field  names  (or  attribute  set). 

(A)  Alert  condition:  The  alert  condition  is  a  logical  expression  in* 
volving  atomic  clauses.  Each  atomic  clause  consists  of  an  attribute 
name  and  a  literal,  or  two  attribute  names,  related  by  a  comparison 
operator  such  as  "=",  "!  =  ",  "<",  ">",  etc.  In  an  alert  condition  for 
type  "m"  update  (record  modification),  the  attributes  are  prefixed  by 
"old"  or  "new",  indicating  whether  an  attribute  refers  to  the  "old"  or 

r*. 

t lie  "new"  record.  Similarly,  in  an  alert  condition  for  type  "i"  up¬ 
date  (record  Insertion),  the  attributes  are  prefixed  by  tiie  "new"  key¬ 
word.  In  an  alert  condition  for  type  "d"  update  (record  deletion), 
the  attributes  are  prefixed  by  the  "old"  keyword.  In  these  two  cases, 
however,  the  prefix  can  be  omitted  since  there  is  no  possibility  for 
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confusion . 


(5)  Action:  The  action  taken  by  a  simple  alerter  when  it  is  triggered, 
is  to  send  messages  to  various  users  or  to  invoke  another  process,  or 
to  perform  database  update  operations. 


(6)  Name  of  creater  of  the  alerter  rule. 

Alerter  rules  are  stored  in  the  alerter  database  (AM)  ,  which  is  also 
managed  by  the  database  system.  Referring  again  to  the  examples  men* 
tioned  in  Section  2.1,  the  messages  to  create  the  appropriate  alerters 


(1)  ADDALERT  a*name="frostwarning" ,  u~type=*"in", 

rel-name*"weather" , 

attribute-name="temp" ,  condition=”new. temp<10  , 
action** "ALERT  user-a  user-b", 
creator="user*c" 

(The  alerter  name  is  "frost-warning" ,  uprla te  type  is  "m",  rela¬ 
tion  name  is  "weather",  attribute  is  "temp",  condition  is 
"new. temp<10" ,  alert  message  should  be  sent  to  "user-a  and 
"user-b",  and  alerter  is  created  by  "user-c".) 

(2)  ADDALERT  a-name=”w.i  thdrawn-warning"  ,  u-type="m", 

rel-name= "account" , 
attribute="balance" , 

cond.i. tion=  "old •  balance  *  new. balance  y  500  , 
action® "ALERT  bank-manager" , 
creator®" teller- a" 


(The  alerter  name  is  "withdrawn-warning",  update  type  is  m  , 
relation  name  is  "account",  attribute,  is  balance  ,  condition  is 
"old . balance-new . balance>500 " ,  alert  message  should  be  sent  to 
"bank-manager",  and  alerter  is  created  by  "teller-a".) 


An  alerter  can  be  removed  by  a  deletion  message: 
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DLTALERT  "frostwarning 


Database  retrieval/update  requests  from  the  user  agent  are  sent  to  the 
database  system.  The  ADDALKRT  and  DLTALERT  messages,  on  the  other 
hand,  are  sent  to  the  alerting  subsystem,  which  then  uses  the  database 
system  to  perform  the  actual  updating  of  the  alerter  database. 

When  tiie  alerting  subsystem  receives  an  ADDALKRT  message,  it  adds  the 
appropriate  alerter  rule  to  the  ADD,  after  checking  that  the  rule  is 
acceptable  (e.g.  the  database  object  does  exist,  and  the  rule  is  con¬ 
sistent  witli  other  rules).  A  message 

ADDEDALT  alert or -name 

is  sent  to  the  agent  creating  the  alerter  rule,  where  "alerter-name" 
is  the  symbolic  name  of  the  alerter  rule.  If  the  alerting  subsystem 
finds  the  alerter  rule  unacceptable,  an  appropriate  error  message  is 
returned . 

Similarly,  when  the  alerting  subsystem  receives  a  DLTALERT  message,  it 
deletes  the  specified  alerter  rule  from  the  ADD  and  sends  the  follow¬ 
ing  response  to  the  agent  deleting  the  alerter  rule, 

DLTEDALT  alerter-name 

When  a  database  retrieval  request  is  sent  to  the  database  system,  it 
simply  retrieves  the  appropriate  information,  and  the  response  from 
the  database  system  is  forwarded  to  the  user.  No  message  is  sent  to 
the  alerting  subsystem.  This  is  because  we  do  not  monitor  retrieval 
operations.  Retrieval  could  be  monitored,  if  we  intend  to  analyze 
user  profile  for  security  or  protection  reasons. 


A. 
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When  a  database  update  request  is  sent  to  the  database  system,  :>  t 
first  performs  the  requested  update  operation.  Only  after  the  update 
has  been  performed ,  that  the  database  system  sends  the  following  mes¬ 
sage, 

UPDATED  <update- type>  <obj-name>  <old-record>  <new-record> 

to  the  alerting  subsystem.  The  alerting  subsystem  then  checks  whether 
any  alert  condition  is  satisfied.  The  simplest  approach  is  to  scan 
through  the  alerter  rules  in  the  alerter  database.  The  alerting  sub¬ 
system  can  use  the  database  system  to  retrieve  alerter  rules  from  the 
alerter  database.  To  improve  efficiency,  the  alerter  rules  could  be 
Indexed  by:  (a)  update  type,  (b)  relation  name,  and  (c)  attribute 
name(s).  With  sucli  an  index  structure,  the  lowest-level  entries  are 
pointers  to  the  alerter  rules.  Only  alerter  rules  pertinent  to  an 
update  need  be  checked.  Therefore,  in  practice,  the  required  computa¬ 
tion  for  ctiecking  ADO  represents  a  small  overhead  on  each  update. 

When  an  alerter  is  triggered,  t he  alerting  subsystem  may  send  alert 
messages  to  the  user  agent,  if  the  specified  action  is  the  ALERT  com¬ 
mand.  The  alert  message  contains  the  name  of  alerter,  type  of  update, 
database  object  monitors,  and  value  of  database  object  before  and 
after  the  update.  The  user  agent  is  responsible  for  processing  the 
ALERT  message.  On  the  other  hand,  the  alerting  subsystem  may  send 
activity  request  to  the  office  manager  for  activity  scheduling,.  The 
activity  request  consists  of  action  names  and  other  parameters,  as 
specified  in  the  alerter  rules. 
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4.  Existential  Alerters  and  Time  Alerters 

Existential  alerters  are  alerters  with  well-defined  duration.  To 
define  duration  of  an  alerter,  we  extend  the  concept  of  simple  alert¬ 
ers  as  follows.  Each  alerter  is  associated  with  three  conditions:  an 
alert  condition,  an  Of’  cond i t i.011 ,  and  an  OEE  condition.  When  the  Of; 
condition  is  met,  the  alerter  is  enabled.  When  the  OFl'  condition  is 
met,  the  alerter  is  destroyed.  The  alert  condition,  as  defined  previ¬ 
ously,  determines  when  the  alerter  rule  is  triggered.  Each  alerter 
thus  monitors  three  database  objects,  one  for  each  of  the  three  condi¬ 
tions.  These  three  monitored  objects  can  be  identical  or  different. 
The  set  of  alerters  that  are  currently  ON  is  called  the  ON- set . 

A  customized  alerter  is  an  alerter  of  the  form  Ak(cl,  c2 ,  ...,  cm) 
where  the  ci.'s  are  parameters  that  may  appear  in  the  alert  condition. 
A  customized  existential  al er ter  is  an  existential  alerter  of  the  form 
Ak(cl,  c2 , . . . ,  cm),  where  the  ei's  are  parameters  that  may  appear  in 
the  alert  condition  or  the  duration  (i.e,  the  ON  condition  and  the  OFF 
condition).  All  customized  alerters  of  an  alerter  Ak  have  the  same 
format  as  Ak ,  except  the  ci's  may  have  different  values  in  each  cus¬ 
tomized  rule. 

A  t I me  alerter  is  a  special  type  of  alerter  for  monitoring  time- 
related  events.  In  order  to  specify  time  alerters,  we  can  assume 
there  is  a  special  relational  file,  coiled  TIME,  which  has  only  one 
attribute  --  time.  The  system  may  update  the  TIME  relational  file 
periodically,  the  update  frequency  being  dependent  on  applications. 
The  TIME  relational  file  may  also  lie  the  system  clock  itself,  and  the 
update  frequency  is  the  same  as  the  clock  rate.  With  this  conceptual 
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time  relational  file,  the  system  can  treat  time  as  an  ordinary  attri¬ 
bute,  and  the  alerter  rule  can  mention  the  time  attribute  in  its  ON 
condition,  trigger  condition,  as  well  as  OFF  condition. 

As  an  example,  suppose  we  want  to  monitor  incoming  telephone  calls. 
The  alerter  is  in  effect  between  8  a.m.  and  11  a.m.,  and  the  trigger 
condition  is  "caller  =  'Smith'”.  The  existential  alerter  is  as  fol¬ 
lows  : 

(1)  ON  condition:  time  =  8  a.m. 

(2)  Alert  condition:  caller  =  'Smith' 

(3)  OFF  condition:  time  =  11  a.m. 

For  this  application,  the  TINE  file  might  be  updated  once  every  five 
minutes . 

The  above  alerter  rule  can  he  modified  to  be  a  customized  alerter  rule 
as  follows.  The  customized  alerter  A(tl,  t2,  caller-name)  has  the 
following  conditions: 

(1)  ON  condition:  time  =  tl 

(2)  Alert  condition:  caller  =  caller-name 

(3)  OFF  condition:  time  =  t2 

Other  system  parameters  can  be  monitored  similarly,  by  creating 
special-purpose  system  relational  files  containing  such  parameters. 
■The  system  overhead  is  proportional  to  the  frequency  of  updates  for 
such  system  files,  because  every  update  of  a  system  file  will  result 
in  the  evaluation  of  alerter  rules  monitoring  this  file.  Therefore, 
we  must  exercise  care  in  determining  how  often  to  update  the  system 
parameters,  such  as  time,  toggle  switch,  etc. 


5.  Journal  Editing  Example 


As  an  example  of  office  automation,  we  will  describe  the  journal  edit¬ 
ing  activities  in  an  editorial  office,  basically,  there  are  three 
activities  to  be  considered:  (a)  occurrence  of  real-world  events,  (b) 
database  update  activities,  and  (c)  generation  of  forms. 

The  occurrence  of  real-world  events  causes  input  messages  to  be  sent 
to  the  office  information  system.  As  illustrated  in  Figure  2,  each 
input  message  is  considered  a  record  insertion  into  a  MESSACE  rela¬ 
tional  file  in  the  user  database  UDB,  which  triggers  alerters  A1  or  A6 
to  invoke  user-defined  processes.  In  actual  implementation,  the  mes¬ 
sage  file  may  he  nonexistent,  or  it  may  serve  as  a  log  file  to  record 
all  incoming  messages.  The  message  file  may  contain  the  following 
attributes:  message- type ,  message-id,  message-text . 

One  type  of  input  message  is  the  submission  of  a  paper  from  an  author. 
This  message,  with  message-type  's',  represents  an  event  which  arises 
from  outside  the  system.  It  triggers  A1  to  invoke  a  (manual  or  au¬ 
tomatic)  data  entry  process  PI  to  enter  the  relevant  information  into 
the  user  database.  In  this  case,  a  new  record  is  inserted  into  the 
PAPEKS  relational  file.  Tlv  PAPEKS  file  has  the  following  attributes: 
paper//,  title,  author,  author-address,  submission-date,  paper-status. 

The  insertion  of  a  new  record  In  PAPEKS  relational  file  triggers 
alerter  A2  to  invoke  two  concurrent  processes:-  (1)  a  form  generation 
process  P2  to  send  an  acknowledgement  letter  (form  F2)  to  the  author; 
and  (2)  a  reviewer  selection  process  P3  to  prompt  the  editor  Lo  select 
three  reviewers.  The  form  generation  process  P2  is  automatic.  The 
process  P3  requires  manual  interaction.  The  interaction  is  accom¬ 
plished  using  a  form  K3. 
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After  the  editor  has  selected  three  reviewers  using  form  F3 ,  process 
P3  causes  the  insertion  of  a  new  record  into  the  REVIEW  relational 
file.  The  REVIEW  file  has  the  following  attributes:  paper//,  re* 
viewerl ,  datel,  stl,  reviewer2,  date2,  st2,  reviewer3,  date3,  st3. 
The  status  of  a  reviewer  is  initially  0.  It  is  set  to  1  when  the 
reviewer  sends  back  the  review,  and  *1  when  he  declines  to  review  the 
paper.  The  insertion  of  a  new  record  in  the  REVIEW  relational  file 
triggers  alerter  A3  to  invoke  a  form  generation  process  P4,  to  send 
letters  (form  F4)  and  copies  of  the  submitted  paper  to  the  reviewers. 
The  reviewer's  name  and  address  can  be  found  in  another  relational 
file  REVIEWER,  which  contains  the  following  attributes:  reviewer/', 
name,  address,  review-area. 

The  alerter  A3  also  generates  an  existential  time-alerter  A4(X,Y,tl), 
for  reviewer  X,  paper  Y,  at  time  tl.  When  a  reviewer  lias  not  respond¬ 
ed  after  a  given  time  interval  (say,  three  months),  A4  is  triggered 
by  the  alerting  subsystem.  A4  invokes  a  form  generation  process  P5,  to 
send  a  letter  (form  F5)  to  that  reviewer  asking  for  response.  The 
alerter  A4  generates  another  existential  time  alerter  A5(X,Y,t2)  and 
then  self-destructs.  It  should  be  noted  that  A4  is  an  existential 
alerter  which  is  automatically  destroyed  when  the  reviewer  send  back 
his  review. 

If  the  reviewer  still  does  not  respond  after  a  given  time  interval,  A5 
is  triggered,  which  again  invokes  process  P3.  The  process  P3  prompts 
the  editor  to  select  another  review,  and  again  updates  the  REVIEW 
relational  file.  After  firing,  the  alerter  A5  also  self-destructs. 
A5  is  also  an  existential  alerter  which  is  automatically  destroyed 
when  the  reviewer  sends  back  his  review. 


Another  type  of  input  message  occurs  when  a  reviewer  sends  hack  his 
review.  Again,  this  message,  with  message-type  'r',  is  considered  as 
an  insertion  into  MESSAGE  relational  file,  which  triggers  alerter  A6 
to  invoke  a  (manual  or  automatic)  updating  process  P6,  to  update  the 
REVIEW  relational  file.  The  update  of  REVIEW  may  cause  the  destruc¬ 
tion  of  existential  alerters  A4  and  A5.  If  all  three  reviews  of  same 
paper  have  come  back,  ( stl=st2=st3=l ) ,  this  will  trigger  alerter  A7, 
which  invokes  an  evaluation  process  P7.  P7  will  require  manual  in¬ 
teraction  with  the  editor  to  determine  status  of  paper.  The  interac¬ 
tion  again  is  accomplished  using  a  form  F7.  A  form  FS  is  generated, 
to  inform  the  author  tint  his  paper  is  (a)  accepted,  (b)  required  to 
be  revised,  or  (c)  rejected.  If  paper  is  accepted  or  rejected,  that 
record  in  PAPERS  relational  file  may  be  moved  to  a  backup  file,  and 
the  corresponding  record  in  REVIEW  relational  file  may  also  be  moved 
to  a  backup  file.  If  paper  is  to  be  revised,  it  stays  in  PAPERS  rela¬ 
tional  file,  and  the  corresponding  record  in  REVIEW  relational  file  is 
updated . 

If  a  reviewer  sends  hack  a  letter,  saying  he  does  not  want  to  review 
the  paper,  then  this  reviewer's  status  is  changed  to  "-1",  and  the 
update  of  the  REVIEW  relational  file  triggers  alerter  A9,  which  again 
invokes  process  P3  to  prompt  the  editor  to  select  another  reviewer, 
and  the  whole  procedure  repeats. 

From  the  above  description,  we  can  see  UTat  messages  can  be  created  by 
the  user  to  represent  outside  events,  or  by  the  system  because  of 
updating  of  relational  files,  user  time  interrupts,  etc.  Eacli  message 
may  trigger  one  or  more  alerters,  which  usually  invoke  processes  to 
perform  some  of  the  following:  (a)  request  additional  information  from 
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the  user,  (b)  update  the  database,  and  (c)  venerate  forms. 


Figure  2  depicts  a  set  of  alerters  to  perform  the  journal  editing 
task.  There  are  two  relational  files:  PAPF.RS  and  REVIEW.  The  MESSACE 
file  could  be  a  nonexistent  file,  or  a  log  file.  Alerters  A2  and  AR 
monitor  the  PAPERS  relationla  file,  and  A3,  A7 ,  and  A9  monitor  the 
REVIEW  relational  file.  A4  and  A5  are  customized  time  alerters,  and 
A5  is  generated  only  when  A4  has  been  triggered.  A4  and  A5  are  both 
customized  for  a  particular  reviewer  X  of  a  particular  paper  Y,  and 
they  either  self-destruct  after  firing,  or  are  destroyed  when  OFF  con¬ 
ditions  are  met,  i.e.  when  the  reviewer  sends  back  his  review.  Figure 
2  also  depicts  the  relationship  among  various  alerters.  The  notation 
introduced  in  the  previous  section  is  used,  but  duplicated  relational 
files  are  drawn  for  the  sake  of  clarity. 

The  above  journal  editing  example  illustrates  the  combination  of  manu¬ 
al  and  interactive  activities  (PI,  P3 ,  PG  and  P7)  with  automated  ac¬ 
tivities  (P2,  P4,  P5  and  P8).  It  also  illustrates  the  usage  of  forms 
for  office  communications.  Forms  lr2 ,  F4 ,  F5,  and  F8  arc  output  forms. 
F3  and  F7  are  interactive  forms,  or  so-called  intelligent  forms ,  which 
requires  manual  interaction.  PI  anti  PG  are  also  interactive 
processes,  because  If  the  input  messages  are  paper  messages  (such  is 
the  case  in  a  conventional  editorial  office),  then  these  input  mes¬ 
sages  must  be  encoded  and  entered  into  Jt he  system.  However,  if  we 
have  an  electronic  mail  system,  then  the  paper  submission  message  is  a 
form  FI,  and  the  review  update  message  is  either  the  returned  form  F4 
or  F5,  and  in  all  these  cases  PI  and  PG  are  automatic  processes. 
Notice  also  in  Figure  2,  Al ,  A4 ,  A5 ,  A6 ,  A7  and  A1)  are  conditional 
alerters.  The  other  alerters  do  not  have  alert  conditions. 


Figure  3  illustrates  the  update  of  the  alerter  database  (Figure  3(a)), 
the  update  of  the  PAPERS  relational  file  (Figure  3(b)),  the  generated 
form  F2  which  is  sent  to  the  author  (Figure  3(c)),  and  the  interactive 


form  F3  which  is  sent  to  the  editor  to  be  completed  and  returned  to 
editorial  office  system  (Figure  3(d)). 
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6.  Alerter  System  Stability 


We  distinguish  an  alerting  subsystem,  which  is  the  physical  implemen¬ 
tation  of  database  alerting  technique,  from  an  alerter  system ,  which 
is  the  abstract  system  of  alerter  rules  driven  by  input  updates.  In 
this  section,  we  discuss  the  problem  of  alerter  system  stability. 

When  alerters  trigger  each  other  in  endless  successions,  Infinite 
message  loops  occur.  Such  infinite  message  loops  are  obviously  un¬ 
desirable,  because  the  alerter  system  is  unstable.  Therefore,  infin¬ 
ite  loop  detection  technique  must  be  devised  to  prevent  sue))  infinite 
message  loops  from  happening. 

To  illustrate  the  concept  of  infinite  loop  detection,  let  us  consider 
the  following  example.  Suppose  the  user  data  base  has  two  relational 
files,  Rl(Dll,  D12)  and  R2(D21 ,D22) .  In  the  alerter  data  base,  there 
are  two  alerter  rules: 

Alerter  Rule  A1 :  If  a  record  (1,  dl2)  in  file  R1  is  modified  to  (1,1), 
then  modify  record  (1,  d22)  in  R2  to  (1,2). 

Alerter  Rule  A2:  If  a  record  (1,  d22)  in  file  R2  is  modified  to  (1,2), 
then  modify  record  (1,  dl2)  in  R1  to  (1,1). 

With  these  two  alerter  rules,  when  a  record  (l,  dl2)  in  R1  is  modified 
to  (1,1),  the  two  alerter  rules  will  be  triggered  successively,  caus¬ 
ing  an  infinite  message  loop.  **' 

Using  the  notation  introduced  in  Section  2.3,  in  the  example  described 
above,  we  have  R1  ->  A1  ->>  R2  ->  A2  ->>  Rl,  thus  forming  a  message 
loop.  Therefore,  we  say  that  alerter  rules  A(l),  A(2),  ...,  A(n)  form 
a  message  loop,  if  there  are  relational  files  R(l),  R(2),  •••,  R(n), 
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such  that  R(  1 )  ->  A ( 1 )  -»  R(2)  ->  A(2)  »  ...  -»  R(n)  ->  A(n)  -» 

H(l). 

The  existence  of  a  message  loop  is  a  necessary  condition  for  the  oc¬ 
currence  of  infinite  message  loops.  However,  whether  an  infinite  mes¬ 
sage  loop  will  occur  is  data  dependent.  As  in  the  above  example,  if 
we  insert  record  (0,  0)  into  relational  file  Ul,  no  infinite  message 
loop  will  occur. 

Therefore,  to  prevent  infinite  message  loops  from  occur.ing,  it  is 
necessary  to  (1)  detect  the  presence  of  message  loops,  (2)  keep  a  his¬ 
tory  of  update  messages  and  alerter  rule  firings  for  every  relational 
file  and  alerter  rule  in  the  message  loop,  and  (3)  break  up  an  infin¬ 
ite  message  loop  when  the  update  message  histories  indicate  such  loops 
are  present. 

The  office  procedure  model  (Off!)  described  in  Section  2.3  is  a  graphic 
representation  of  the  relationships  among  office  activities,  data¬ 
bases,  and  alerters,  for  each  specific  database  update,  we  call  the 
description  of  its  relationship  with  the  alerter  rule  triggered  and 
activities  performed  a  run-time  0PM  instance .  The  history  of  the 
alerting  system  actually  consists  of  a  collection  of  such  run-time  OPM 
instances.  In  the  above  infinite  message  loop  detection  scheme,  Part 
(1)  requires  a  static  analysis  of  the  OPM  model  to  detect  the  message 

loop.  Part  (2)  and  Part  (3)  requires  dynamic  monitoring  of  OPM  run* 

«•  — 

time  instances  within  the  message  loop. 

The  detection  of  message  loops  can  be  achieved  as  follows.  Each  rela¬ 
tional  file  can  be  represented  as  a  node  in  a  directed  graph  derivable 
from  the  OPM  model.  If  there  are  Hi,  Ai  and  Rj  such  that  Rl->Ai->>Rj, 
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an  arc  will  be  drawn  from  Ri  to  Rj,  with  the  arc  labelled  as  A  5. .  The 
existence  of  a  loop  in  the  graph  indicates  the  existence  of  a  message 
loop  among  the  alerter  rules.  Whenever  a  new  alerter  rule  is  added  to 
the  alerter  database  or  an  old  alerter  rule  is  updated,  the  system 
modify  the  OPM  model,  constructs  the  directed  graph,  and  checks  wheth¬ 
er  a  message  loop  exists. 

We  now  demonstrate  that  under  certain  conditions,  infinite  message 
loops  can  be  detected.  Let  u,  v  denote  records  (or  tuples)  in  a  rela¬ 
tional  file  R.  An  update  operation  is  denoted  by  (u,  v) ,  where  u  is 
the  record  to  be  deleted,  and  v  is  the  record  to  be  inserted.  If  u  is 
not  in  R,  or  v  is  already  in  R,  the  update  operation  (u,  v)  is  unde¬ 
fined.  An  insertion  operation  is  denoted  by  (0,  v) ,  and  a  deletion 
operation  is  denoted  by  (u,  0),  where  0  denotes  the  empty  set. 

Suppose  Ai  monitors  Ri.  The  trigger  region  Bi  of  Ai  is  defined  to  be, 

111  =  {  (u,v):  u,  v  in  R_i  and  (u,v)  triggers  Ai} 

where  Ri  is  the  underlying  domain  of  Ri. 

Suppose  Ai  monitors  Ri  and  Ai  affects  Rj.  The  notation,  (ui,  vi)  -> 
Ai  -»  (uj,  vj)  indicates  that  an  update  operation  (ui,  vi)  on  Ri  will 
trigger  Ai  (i.e.  (ui,  vi)  is  in  Bi),  and  Ai  causes  an  update  operation 
(uj,  vj)  on  Rj. 

If  we  denote  (ui,  vi)  by  wi  and  (uj,  vj)  b*  w j ,  wc  can  simply  write  wi 
->  Ai  -»  w j .  In  other  words,  we  have  a  mapping  f  such  that  f(wi) 
w j .  Each  component  of  the  mapping  is  denoted  by  fk,  and  fk(w.l)  =  wjk, 
where  wjk  is  the  k-th  component  of  wj. 

The  alerter  Ai  is  information  reducing,  if  for  every  pair  of  (wi,  wj) 
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such  that  wi  - >  Ai  -»  w j ,  each  component  I'k  of  the  mapping  f  is  ei¬ 
ther  a  generalized  identity  function  (i.c.  wjk  =  fk(wi)  =  wix  for  some 
x) ,  or  a  finite  classifier  (i.e.  the  range  of  fk  is  finite). 

If  wi  ->  Ai  ->>  wj  and  Ai  is  information  reducing,  then  wj  has  a  fin¬ 
ite  range. 


If  there  is  an  infinite  message  loop,  then  for  some  Ri  ->  Ai  ->>  Rj  in 
a  message  loop,  there  are  infinite  sequences  of  update  operations 


12  3  n  12  3  n 

w  ,  w  ,  w  ,  . w;  and  w  ,  w  ,  w  ,  . w  ,  such  that 

i  i  i  j  j  j  j 

k  k 

w  ->  A  ->>  w 

i  i  j 


for  all  k.  Since  wi  has  finite  range,  we  must 
some  numbers  M  and  M. 


M 
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N 

w  for 

j. 


Therefore,  we  may  wish  to  restrict  the  alerters  to  information  reduc¬ 
ing  alerters.  Under  such  constraints,  we  can  dynamically  determine 
whether  an  infinite  message  occurs  by  observing  whether  some  wi  re¬ 
curs,  for  some  Ri  within  a  message  loop. 

We  now  describe  a  method  to  record  the  run-time  Ol’M  instance  for  mes¬ 
sage  loop  detection.  Whenever  the  alerter  database  is  updated,  the 
activity  management  system  checks  whether  a  message  loop  lias  been 
formed.  If  a  message  loop  is  detected , ^additional  alerter  rules  can 
be  added  automatically  by  the  activity  management  system,  one  rule  Ai 
for  each  relational  file  Ri  in  the  message  loop.  Subsequently,  when¬ 
ever  Ri  is  updated,  Ai  is  always  triggered  to  record  the  update  mes¬ 
sage  into  a  log  file.  The  log  file  Is  a  protected  special  relational 
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file  in  the  UDU .  The  log  file  is  indexed  by  (a)  file  name,  and  (b) 
user  process-id.  In  other  words,  a  history  of  update  messages  is  kept 
for  each  (file  name,  user  process-id)  pair.  The  user  process-id  is 
the  original  user  process-id  which  initiates  the  first  update  to  a 
relational  file  in  a  message  loop.  In  the  above,  we  have  shown  that 
if  the  alerter  rules  are  information  reducing ,  then  by  observing 
whether  there  is  a  recurrence  of  update  message  in  an  update  history, 
the  occurrence  of  infinite  message  loops  can  be  dynamically  detected. 

In  practice,  instead  of  keeping  update  message  histories  in  the  log 
file,  we  can  keep  a  conuntcr  for  each  (file  name,  user  process-id) 
pair.  Each  file  update  will  increment  the  counter  by  one.  When  a 
counter  reaches  a  perdctermj.ned  threshold,  the  loop  is  broken  by  (a) 
blocking  the  update  message  having  the  same  file  name  and  original 
process-id,  and  (b)  sending  a  report  to  t he  user. 

Instead  of  keeping  a  log  file  or  even  a  simplified  log  file  as  sug¬ 
gested  above,  we  can  include  a  f rcquency  s tamp  in  each  message  to 
store  a  count  of  how  many  times  this  message  has  looped  through  the 
activity  management  system.  The  activity  management  system  is  respon¬ 
sible  for  assigning  proper  values  to  the  frequency  stamp.  The  fre¬ 
quency  stamp  is  usually  inherited  from  the  input  message.  When  the 
input  message  docs  not  have  its  frequency  stamp  specified,  the  activi¬ 
ty  management  system  will  then  assign  an  appropriate  value  to  the  fre¬ 
quency  stamp,  as  to  be  described  below.  When  the  alert  condition  of 
an  alerter  rule  is  satisfied,  the  frequency  stamp  of  the  input  message 
is  incremented  by  one.  If  this  value  exceeds  a  preset  threshold,  the 
activity  management  system  will  break  this  loop  by  not  triggering  the 
alerter,  and  the  user  is  notified.  Otherwise  the  activity  management 


system  will  assign  this  frequency  stamp  to  all  output  messages  gen¬ 
erated  by  this  alerter  rule. 

If  the  messages  are  fedback  directly  to  the  activity  management  sys¬ 
tem,  then  the  frequency  stamps  will  he  transmitted  and  incremented  as 
described  above.  When  t he  message  is  to  activate  an  external  process, 
we  cannot  expect  the  external  process  to  transmit  the  frequency  stamp. 
Therefore,  whenever  an  alerter  invoked  an  external  process,  the  fre¬ 
quency  stamp  associated  with  this  process  is  stored  in  a  frequency 
scamp  table,  which  contains  the  name  of  the  process,  and  its  frequency 
stamp.  Whenever  the  activity  management  system  receives  an  update 
message  with  an  unspecified  frequency  stamp,  it  will  consult  the  fre¬ 
quency  stamp  table  to  determine  whether  this  message  is  caused  by  some 
alerter  rule  previously.  If  this  is  the  case,  then  the  process  name 
associated  with  the  current  message  will  be  a  doscendent  process  of 
some  process  recorded  in  the  frequency  stamp  table.  The  current  pro¬ 
cess  should  then  inherit  the  frequency  stamp  of  the  ancestor  process, 
and  the  unspecified  frequency  stamp  is  thus  specified.  Otherwise,  the 
frequency  stamp  field  of  this  message  is  set  to  the  initial  value.  0. 

Proper  garbage  collection  work  need  to  be  performed  to  maintain  the 
frequency  stamp  table.  A  process  can  be  removed  from  the  frequency 
stamp  table  when  it  ceased  to  be  active.  In  practice,  we  can  simply 
implement  the  frequency  stamp  table  as  a  ring  structure  with  some  rea¬ 
sonable  number  of  entries.  For  example?  the  number  of  onLries  may  be 
equal  to  twice  the  maximum  number  of  active  processes  allowed  by  the 
operating  system.  When  a  new  entry  is  inserted  into  the  frequency 
stamp  table,  this  will  eliminate  the  oldest  entry  from  the  table. 
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7.  Discussions 


In  this  paper,  we  propose  to  use  database  alerting  techniques  for 
office  activities  management.  The  role  of  an  activity  management  sys¬ 
tem  In  an  office  information  system  is  clarified,  and  techniques  for 
mainitaining  alerter  system  stability  are  discussed.  A  unified  for¬ 
malism  to  describe  an  office  procedure  model  has  been  presented  in 
Section  2.3.  A  diagram  such  as  Figure  2  then  represents  the  office 
activities  at  one  work  station.  Similar  diagrams  can  be  constructed 
for  other  work  stations,  and  together  they  can  be  used  to  represent  a 
distributed  office  information  system  (DOIS).  Such  a  model  can  be 
called  a  d 1st  rib uted  office  procedures  mod  e 1  (DOPfi ) . 

An  example  distributed  office  procedure  model  for  a  three-node  (or 
three-station)  distributed  office  information  system  is  illustrated  in 
Figure  4.  It  can  be  seen  that  a  distributed  database  management  sys¬ 
tem  (DDllMS)  is  needed  to  support  a  distributed  office  information  sys¬ 
tem.  Problems  of  infinite  message  loops,  deadlocks,  concurrency  con¬ 
trol,  data  consistency,  and  process  conflicts  must  be  analyzed  care¬ 
fully.  because  of  the  complexity  of  distributed  office  information 
systems  and  the  evolutionary  nature  of  sucli  systems,  it  is  expected 
that  more  and  more  emphasis  will  be  placed  on  t he  incorporation  of 
knowledge  (such  as  alerter  rules,  database  skeletons  [CHAKC78a] ,  and 
office  procedure  models)  into  such  systems,  so  that  it  can  function 
properly  and  provide  adequate  support  for  both  routine  activities 
management  and  decision-making. 
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Figure  1 


Component  Subsystems  of  an  Office  Information  System 
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Office  procedures  Model  for  the  editorial  office 
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